+@jwnimmer-tri for feature review, please.
+@sherm1 for platform review, please.

Comments from Reviewable

Maybe in future for fundamental changes like this that are going to create a lot of conflicts, send out some advanced warning.

a discussion (no related file):
Sorry, I should have opened a discussion thread:

Can we trickle this in, maybe? Just do the @// to @drake// rename in the BUILD file citations in a first PR?

Comments from Reviewable

Review status: 0 of 16 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

a discussion (no related file):
I'm also curious to know what external project we are targeting. I am hesitant to try to support anything like this until and unless we add Drake CI support for a downstream project using us in this fashion.

Comments from Reviewable

@jamiesnape Sorry about that, this seemed like a relatively small change that would enable devs / external users to easily consume drake as an external in Bazel. If this inhibits / conflicts with someone else's PR in flight, we could always block this one until the others go in, and let that serve as the warning.
That being said, I would like to get this in, as it would make things a little simpler for prototyping work.

Are there any PRs in particular that you are concerned about? VTK and install script stuff?

Review status: 0 of 16 files reviewed at latest revision, 2 unresolved discussions.

a discussion (no related file):

Yup, shall do.

a discussion (no related file):

Right now, I am thinking of my own projects for one-off prototypes to inform design decisions.

Could we not use a dummy external in CI to get this workflow started as soon as possible?
(It could also be used to test CMake / pkg-config / cps integration as well.)

And this is not critical to be in master, but if it were not to make it into master at this point, I would probably maintain my own devel branch and merge things into it so I could use this setup, as it is quite useful to me.

Comments from Reviewable

Sorry, @EricCousineau-TRI -- this is too far outside my area of expertise to be an effective platform reviewer for it.
-@sherm1

Review status: 0 of 16 files reviewed at latest revision, 2 unresolved discussions.

Comments from Reviewable

I will wear the platform hat; just fine a second for feature review too, please.

Comments from Reviewable

@sherm1 @jwnimmer-tri sounds good!

+@jamiesnape for feature review, if you are available?
If this messes up any PRs in flight for VTK / install, could you just block on this PR?

Comments from Reviewable

I am. No need to block if this makes your life easier.

Review status: 0 of 14 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

a discussion (no related file):

I definitely agree this moves us toward a better long-term goal. I am fine for a small dummy in CI to prove this works. (I didn't mean to imply that Spartan or something big or difficult should go into our CI).

I would just ask to see the dummy stood up soonish, secured onto this PR train. If it were prototyped such that I could test it locally outside of CI while reviewing the WORKSPACE part of the next PR, all the better. It sound like you have a small downstream project working locally; getting (a cut-down version of that) into RobotLocomotion would be excellent.

Comments from Reviewable

a discussion (no related file):

Awesome. I actually have a simple external based here:
https://github.com/EricCousineau-TRI/drake_external#testing

It has a minimal set of bash commands to clone the repository, and build what is needed.
It could be extended to use whatever the Bazel-only dependencies of install is, such that everything exposed externally is built.

Would that work?

Comments from Reviewable

Review status: 0 of 14 files reviewed at latest revision, 1 unresolved discussion.

a discussion (no related file):

Using Matt's //drake:install dependency, getting some failures in the external. Will see if I can fix that.

Comments from Reviewable

Reviewed 14 of 14 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

a discussion (no related file):

A RobotLocomotion/drake-examples repo that Jenkins just clones and then runs bazel test ... and mkdir build && cmake .. && make && ctest . would work for me. It would be easy to run on continuous.

Comments from Reviewable

That being said, I would like to get this in, as it would make things a little simpler for prototyping work.

Similar - I started doing this (i.e. a bazel workspace chained drake) just to write some simple drake experiments to understand the code and learn a bit of bazel free of all the drake noise. That's turned into unofficially starting work on a canonical set of simple user projects (shambhala) that can be a template (and possibly a CI test later) for others.

This use case should be both the simplest, and a very standard use case. I think it's a good baseline requirement to help drive conventions for our bazel layout in way that helps users (and that requirement won't change). i.e. it's not a parallel support case and better now than a major refactor later.

Aside from the dependencies, be nice to also have access to some of the other bazel infra drake is building - e.g. github.bzl, bitbucket.bzl, install.bzl.

Comments from Reviewable

Reviewed 14 of 14 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

Yes, it has to be an RL repository not personal repo.

We've talked about writing up canonical examples of how to integrate Drake into downstream projects. I think we should probably have one CMake example and one Bazel-only example, completely separate, and that this PR is towards the latter (Bazel-only). So RobotLocomotion/drake-example-bazel maybe?

I don't think it needs to do bazel run -- :install; just having some sample C++ code that deps on Drake libraries should be good enough for now.

a discussion (no related file):
Please take a look at the bzl files in ./third_party/kythe/tools/build_rules/config; I think a few of them also need a @drake// change.

tools/gtest.BUILD, line 34 at r1 (raw file):

    linkopts = select({
        "@drake//tools:linux": ["-pthread"],
        "@//conditions:default": [],

Meta Could you explain why the @//conditions:default doesn't turn into @drake//conditions:default? (Same for spdlog.)

Comments from Reviewable

Looks cool. Just let me know if/when you want a Jenkins job setting up. Should be pretty easy.

Review status: all files reviewed at latest revision, 3 unresolved discussions.

Comments from Reviewable

a discussion (no related file):

I wasn't intending to drop shambhala into RobotLocomotion and CI just yet, but that was the goal.

Comments from Reviewable

a discussion (no related file):

Looking at that now - I feel a little dirty dropping @drake// in a third party, even if it is relatively small.
I will see if I can proxy pkg_config_package to explicitly specify build_file_template as @drake//....

Comments from Reviewable

a discussion (no related file):

If you git blame those lines, IIRC you'll see I've already had to fork them to change their paths for Drake's use.

Comments from Reviewable

a discussion (no related file):

Oh lol, well, then I'll add that in.

However, it seems that we can provide an upstream update to kythe in much the same way - make its paths robust against being used as an external.

Comments from Reviewable

I've pulled and tested this locally with TRI-internal users of Drake, and all seems fine.

Review status: all files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

Fine by me. I was like "meh" at the time.

Comments from Reviewable

Review status: 11 of 19 files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

Hmm... Just successfully ported kythe to its own package, but now it makes me kinda meh as well.
Let me know if you'd like me to roll that change back.

I've updated the example to consume @drake//drake:libdrake.so (as data), and it seems to work out, at least the for the targets that it consumes:
EricCousineau-TRI/drake_external@2e6e75a

tools/gtest.BUILD, line 34 at r1 (raw file):

Done.

Comments from Reviewable

Reviewed 8 of 8 files at r2.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

OK The kythe thing is fine.

FYI I think the Bazel example we end up putting in RobotLocomotion should not use libdrake.so but rather the regular Bazel cc_library stuff via labels.

WORKSPACE, line 19 at r2 (raw file):

workspace(name = "drake")

BTW Is this two blank lines now? Seems excessive.

Comments from Reviewable

Review status: 18 of 19 files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

Sounds good!

WORKSPACE, line 19 at r2 (raw file):

Done.

Comments from Reviewable

Review status: 18 of 19 files reviewed at latest revision, 2 unresolved discussions.

a discussion (no related file):

A cc_library(name = "drake") or all the component libraries?

Comments from Reviewable

a discussion (no related file):

Seems like a good idea to me! Threw it in here for grins, but can defer that to some other PR.

Comments from Reviewable

Reviewed 1 of 1 files at r3.
Review status: 19 of 20 files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

FYI I think doing an example like this would be best:

cc_binary(
    ....
    deps = [
        "@drake//drake/systems/analysis",
        "@drake//drake/systems/framework",
        "@drake//drake/systems/primitives:constant_value_source",
    ],
)

So using per-directory rollup libraries where appropriate, and small libraries otherwise.

drake/BUILD, line 27 at r4 (raw file):

    name = "drake",
    deps = _LIBDRAKE_COMPONENTS,
)

Nope. The uberlibrary should only be for CMake export / binary installation. It should not be a public Bazel export.

Comments from Reviewable

Review status: 19 of 20 files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

True, for external projects, but for the test, would it be more useful to include the megalib?

Added an example of Jamie's suggestion on the downstream thing (adding //drake/solvers):
EricCousineau-TRI/drake_external@07b0e28

Comments from Reviewable

drake/BUILD, line 27 at r4 (raw file):

For external testing with Bazel, it'd still be nice to get to all of the projects, and not have to sync it.

Mayhaps, in something like //tools/library.bzl, we can define something like libdrake_components(), such that they could be imported, via:

load("@drake//tools:libdrake.bzl", "libdrake_components")

Comments from Reviewable

Review status: 19 of 20 files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

We should be exposing the same interface regardless of the build system someone is using to consume it.

Comments from Reviewable

Review status: 19 of 20 files reviewed at latest revision, 2 unresolved discussions.

a discussion (no related file):

Let's have that debate somewhere else? libdrake.so is not the final answer, so I don't want to export it publicly from Bazel.

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions.

a discussion (no related file):

Ok.

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions.

drake/BUILD, line 27 at r4 (raw file):

Reverted. Will create a separate issue on this.

Comments from Reviewable

Reviewed 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Reviewed 7 of 8 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

Comments from Reviewable

"unstable due to git failures" flake
@drake-jenkins-bot linux-xenial-gcc-ninja-experimental please

FYI I just dismissed @stonier's blocking discussion comment, which I presume was accidental.

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable

Awesome, thanks!